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Sir: 

We, Douglas M. Dillon and Vivek Gupta, hereby declare that: 

1 . We are the inventors of the inventions described and claimed in 
the above-identified patent application. 

2. Prior to March 6, 1998, we conceived in the United States the 
inventions set forth in Claims 17, 18, 21 through 24, 26 through 28, 31 through 34. 
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36, 37, 47, 48, 51 through 54, 56, and 57 of the above-identified patent 
application, as set forth in the Claim Sheet attached as Exhibit 1 . 

3. Also prior to that date, we prepared a description entitled 
"DirecPC Turbo-Throttling Feature Requirements Specification". 

4. A copy of the description from which dates have been redacted is 
attached as Exhibit 2. 

5. The description evidences the conception of the inventions of the 

claims. 

6. With respect to Claims 1 7, 21 , 22, 26, 27, 31 , 32, 36, 37, 47, 51 , 
52, 56, and 57, conception is evidenced, e.g., by the reference in the description 
that the hybrid gateway (HGW) maintains a running average throughput for a user 
and if the user's throughput exceeds a threshold, the user's TCP window size may 
be clamped, and by the references to "per user" throttling and the reference in the 
description to "service plan". (See, e.g.. Exhibit 2, §§ 3.1 .1 through 3.1 .6. and 
Turbo-Throttling II" Data Sheet.) 

7. With respect to Claims 18, 28, and 48, conception of amount of 
data per unit time is evidenced, e.g., by the mention of measures such as kbps 
and MB/hr. (See, e.g.. Exhibit 2, Parameters for Turbo-Throttling II Data Sheet.) 

8. With respect to Claims 23, 33, and 53, conception of throttling in 
accordance with the "number of TCP connections" and the "level of service" is 
evidenced, e.g., by the references in the description to the number of TCP 
connections being limited to the MaxConnections configured for the corresponding 
service plan. (See, e.g., Exhibit 2, § 3.1 .7.) 
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9. With respect to Claims 24, 34, and 54, conception is evidenced, 
e.g., by the description mentioned above in paragraph 6 of this declaration, 
together with the references to (a) "bucket leak" and (b) either window size 
clamping or discarding UDP packets. (See, e.g., paragraph 6, supra , as well as 
Exhibit 2, §3.1.8.) 

10. Thereafter, and prior to March 6, 1998, we constructed an 
actual device implementing the inventions of the foregoing claims. 

1 1 . The device operated successfully prior to that date. 

12. This evidenced by an email that my coworker Rod Ragland sent 
out prior to March 6, 1998. 

1 3. In that email, he indicated that he would analyze statistics from 
the "Turbo-Throttle II gateways". 

14. A copy of that email from which dates and information relating to 
matters other than Turbo Throttling have been redacted is attached as Exhibit 3. 

1 5. That the device operated successfully prior to March 6, 1 998, is 
further evidenced by an email that my coworker Harvey Lindenbaum sent prior to 
that date. 

16. In that email, he indicated that "FIT testing of Turbo Throttling 2 
has been completed". 

17. This means that all aspects of the project were successfully 

tested. 
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18. A copy of his email from which dates and information relating to 
matters other than Turbo Throttling has been redacted is attached as Exhibit 4. 

19. I hereby declare that all statements made herein of my own 
knowledge are true and that all statements made on information and belief are 
believed to be true, and further that these statements were made with the 
knowledge that willful false statements and the like so made are punishable by 
fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code, and that such willful false statements may jeopardize the validity of this 
application and any patent issuing thereon. 
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I hereby certify that this correspondence is being deposited with the United States 
Postal Service as first-class mail in an envelope addressed to Mail Stop AF, 
Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on 
FcJ>. ^ 2006. 




Craig Plastrik 
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CLAIM SHEET 

17. A gateway for use in a system wherein a first apparatus, said 
gateway, and a second apparatus are in a TCP/IP network, wherein the source 
apparatus, said gateway, and the second apparatus have different IP addresses, 
said gateway comprising: 

a packet receiving unit that is configured to receive a packet addressed 
at the IP level from the first apparatus to the second apparatus; and 

a service plan determining unit that is configured to determine a level of 
service subscribed to by a user of the first apparatus; 

a throttling unit that Is configured to throttle the user of the first apparatus 
by (a) adjusting the transport level window size of the packet in accordance with 

(1 ) the level of service subscribed to by the user of the first apparatus and 

(2) bandwidth usage associated with the user of the first apparatus, and (b) 
sending the so adjusted packet to the second apparatus, 

wherein the packet received by said packet receiving unit has, as its 
source IP address, the IP address of the first apparatus, and has, as its 
destination IP address, the IP address of the second apparatus. 

18. A gateway according to Claim 17, wherein the bandwidth usage is 
measured as an amount of data per unit of time. 
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21 . A gateway according to Claim 1 7, wherein the bandwidth usage is 
expressed as an average throughput. 

22. A gateway according to Claim 17, wherein the bandwidth usage is 
determined using a leaky bucket analysis. 

23. A gateway for use in a system wherein a source first apparatus, 
said gateway, and a second apparatus are in a TCP/IP network, each of the first 
apparatus, said gateway, and the second apparatus having different IP 
addresses, said gateway comprising: 

a throttling unit that is configured to (a) determine the number of TCP 
connections that are open and (b) throttle a user of the first apparatus in 
accordance with (1 ) the determination of the number of TCP connections that are 
open and (2) a level of service subscribed to by the user of the first apparatus. 

24. A gateway for use in a system wherein a first apparatus, said 
gateway, and a second apparatus are in a TCP/IP network, each of the first 
apparatus, said gateway, and the second apparatus having different IP 
addresses, said gateway comprising: 

a throttling unit that is configured to throttle a user of the first apparatus 
in accordance with (1) a leaky bucket analysis of the user's throughput and (2) a 
level of service subscribed to by the user, 
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wherein said throttling unit intercepts a packet on a TCP/IP connection 
between the first apparatus and the second apparatus; and 

wherein one of the following two conditions is satisfied: (1) said throttling 
unit effects the throttling by discarding the packet and (2) said throttling unit 
effects throttling by modifying a field in the packet. 

26. An apparatus according to Claim 17, wherein said throttling unit 
compares bandwidth usage to a threshold. 

27. A method for use in a system wherein a first apparatus, a gateway, 
and a second apparatus are in a TCP/IP network, each of the first apparatus, the 
gateway, and the second apparatus having different IP addresses, said method 
comprising: 

intercepting by the gateway of a packet addressed at the IP level from 
the first apparatus to the second apparatus; and 

determining a level of service subscribed to by a user of the first 
apparatus; 

determining whether or not to throttle a user of the first apparatus in 
accordance with (a) the level of service and (b) bandwidth usage by the user; 

throttling by the gateway of the user of the first apparatus in accordance 
with a determination in said determining step that the user of the first apparatus 
should be throttled, said throttling comprising (1) adjusting, by the gateway, of the 
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transport level window size of the packet received in said receiving step and (2) 
sending the so adjusted packet to the second apparatus, 

wherein the packet received in said receiving step has, as its source IP 
address, the IP address of the first apparatus, and has. as its destination IP 
address, the IP address of the second apparatus. 

28. A nnethod according to Claim 27, wherein the bandwidth usage is 
measured as an amount of data per unit of time. 

31 . A method according to Claim 27, wherein the bandwidth usage is 
expressed as an average throughput. 

32. A method according to Claim 27, wherein the bandwidth usage is 
determined using a leaky bucket analysis. 

33. A method comprising: 

determining a number of TCP connections that are open; and 
throttling, by a gateway for use in a system wherein a first apparatus, the 
gateway, and a second apparatus are in a TCP/IP network, of a user of the first 
apparatus, in accordance with (1 ) the determination of the number of TCP 
connections that are open and (2) a level of service subscribed to by the user. 
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34. A method comprising: 

throttling by a gateway for use in a system wherein a first apparatus, the 
gateway, and a second apparatus are in a TCP/IP network, of a use of the first 
apparatus, in accordance with (1 ) a leaky bucket analysis of the user's throughput 
and (2) a level of service subscribed to by the user, 

wherein the first apparatus, the gateway, and the second apparatus have 
different IP addresses, and 

wherein the gateway intercepts a packet on a TCP/IP connection 
between the first apparatus and the second apparatus and wherein one of the 
following two conditions are satisfied: (1) said throttling comprises discarding of 
the packet and (2) said throttling comprises modifying a field in the packet. 

36. A method according to Claim 34, wherein said throttling step 
comprises modifying the transport level window size field of the packet in 
response to bandwidth usage exceeding a threshold. 

37. A gateway according to Claim 1 8, wherein the transport level 
window size is the TCP window size field of the packet. 

47. A gateway for use in a system wherein a first apparatus, said 
gateway, and a second apparatus are in a TCP/IP network, each of the first 
apparatus, said gateway, and the second apparatus having different IP 
addresses, said gateway comprising: 



-5- 



PATENT 

Attorney Docket No.: PD-970636A 
Customer No.: 29158 

packet receiving means for receiving a packet addressed at the IP level 
from the first apparatus to the second apparatus; 

service plan determining means for determining a level of service 
subscribed to by a user of the first apparatus; and 

throttling means for throttling a user of the first apparatus by adjusting the 
transport level window size of the packet received by said packet receiving means 
in accordance with (1 ) the level of service subscribed to by the user of the first 
apparatus and (2) bandwidth usage associated with the user of the first apparatus, 

wherein the packet received by said packet receiving means of said 
gateway has, as its source IP address, the IP address of the first apparatus, and 
has, as its destination IP address, the IP address of the second apparatus. 

48. A gateway according to Claim 47, wherein the bandwidth usage Is 
measured as an amount of data per unit of time. 

51 . A gateway according to Claim 47, wherein the bandwidth usage is 
expressed as an average throughput. 

52. A gateway according to Claim 47. wherein the bandwidth usage is 
determined using a leaky bucket analysis. 

53. A gateway for use in a system wherein a first apparatus, said 
gateway, and a second apparatus are in a TCP/IP network, each of the first 
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apparatus, said gateway, and the second apparatus having a different IP address, 
said gateway connprising: 

throttling nneans for deternnining a number of TCP connections that are 
open and for throttling a user of the first apparatus, in accordance with (1 ) the 
determination of the number of TCP connections that are open and (2) a level of 
service subscribed to by the user. 

54. A gateway for use in a system wherein a first apparatus, said 
gateway, and a second apparatus are in a TCP/IP network, said gateway 
comprising: 

throttling means for throttling a user of the first apparatus, in accordance 
with (1 ) a leaky bucket analysis of a user's throughput and (2) a level of service 
subscribed to by the user, 

wherein said throttling means intercepts a packet on a TCP/IP 
connection between the first apparatus and the second apparatus, and 

wherein one of the following conditions is satisfied: (1) said throttling 
means effects the throttling by discarding the packet and (2) said throttling means 
effects the throttling by modifying the packet. 

56. An apparatus according to Claim 53, wherein said throttling means 
compares bandwidth usage to a threshold. 
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57. A gateway according to Claim 48, wherein said throttling means 
modifies the TCP window size field of the packet. 
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Chapter 1 
Introduction 

1.1 Purpose 

The purpose of this document is to define the requirements for the DirecPC Turbo-Throttling feature. This 
document has severa! goals: 

• Establish a basis for agreement between Engineering and various operating divisions of HNS about 
what the product must do to meet the needs of the customer and those who must manufacture, 
support, and maintain it; 

• Provide a basis for generating a project plan, estimating costs and schedules; 

• Provide a basis for validation and verification of the final product; 

• Provide a basis for maintenance and enhancement of the product. 

1 .1 ,1 Intended Audience 

This document is applicable to all of the HNS operating divisions that will fund, implement, manufacture, 
sell, use, maintain, and support this capability such as: 

• Hardware and Software Engineering 

• Production, Quality Assurance, and System Test 

• Field Services (Installation and Maintenance) 

• Customer Services - Training, Support, Documentation 

• Program Management 

• Marketing 

• Applications Programmers 

• Legal 

At the discretion of Program Management, some portions of this document may be disclosed to 
prospective customers. 

1.2 Scope 

This document defines the requirements for the Turbo-Throttling feature as it affects the DirecPC NOC 
and Remote software. 

1.3 Terminology 

It is expected that all requirements and capabilities listed in this document will be implemented for the 
current release and all future releases of this system. Each requirement in this document must be 
identified using one of the notations described in Table 1 : 
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Table 1. Requirements Criteria 



[R:nnnn] 


Indicates meeting this requirement is required 


[0:nnnn} 


Indicates meeting this requirement is an objective. An objective is within the 
current scope of the features, but may be sacrificed to meet schedule 


[D:nnnn] 


Indicates meeting this requirement is desirable. A desirable requirement is one 
which would be nice to have, but has been prioritized as not being important 
enough to actually build. A desirable requirement is not within scope (will not be 
built). 


[X:nnnn] 


Indicates a requirement which was suggested at one time, but which has already 
been decided as not something we are at ail interested in doing. Xinnnn 
requirements are sometimes left in a document to document that a requirement 
has been specifically rejected 



Together the letters R, O. and D, and the nnnn portion of the notation form a Document-Unique 
Reauirernent ID (DURID) that uniquely identifies the requirement The nnnn portion of the DURID can be 
any numeric value as long as it. together with the letter R. O. or D form an ID that is unique across the 
whole document. The document number + DURID form a primary key used to identify a specific 
requirement in a requirements traceability matrix. 
The following is a list of constraints related to the use of DURIDs: 

. DURIDs must be enclosed in. square brackets Q and only one DURID must be enclosed in a set of 
brackets. This is to ensure consistent markup and facilitate future automated requirement lookup 
schemes. 

. DURIDs should be placed after paragraph numbers and at the beginning of each requirement listed. 
. Once a DURID is assigned to a requirement, it must never change. 

• DURIDs identify a single requirement for the life of that requirement. 

. DURIDs should not be reused when a requirement is deleted if a-requirements traceability matrix 
already exists for the feature described by this document 

• DURIDs can be duplicated If they are in different documents. 

. The nnnn portion of the DURID should be unique across the document without regard to the DURID 
letter portion This allows a document writer to more easily detennine the next available DURID 
number because the combination of letter + number does not need to be taken into account. This 
would also enable development of an automated DURID numbering macro, for instance, to be 
simplified. 

The following are examples of requirements Identified using the DURID notaUon: 
3.1 .2. IR:0001 1 A Requirement To Do TTiis Thing 

3.1 .2. [0:0002] This Thing Should Be An Objective 

3.1 .3. [0:0003] A Desire To Do This^ther Thing 

1 .4 Definitions and Acronyms 

This section provides definitions for all acronyms and temis introduced in or unique to this document 
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Table 2. Definitions and Acronyms 



Term 


Description 


Customer/User 


The end user of the DirecPC software 


NOC 


DirecPC Network Operations Center 


DirecPC Access Kit 
(DAK) 


The hardware and software that comprises the remote DirecPC product 


HGW 


Hybrid Gateway 



1.5 References 

[1] DirecPC Turbo-Internet Statistics Feature Requirements Specification 
[2] DirecPC Turbo-Internet Statistics Feature Design Specification 

1.6 Open Issues 



• There are no open issues 
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DirecPC^'^ Turbo-Throttling 




The DirecPC Turbo-Throttling feature provides the additional capabilities to DirecPC Turbo- Id temet to support an 
enforced running average fair use policy and also perfonnance-differentiated levels of service. The highlights of 
Turbo-Throttling include: 

• Maintaining a running average of the user's total throughput. The running average calculation is based on the 
leaky-bucket approach used for rate-based flow control in ATM and Frame Relay. The ninning average is 
maintained across user sessions. 

• Assigning an intial per-conncction TCP window size WMax to each user and clamping it to Wl or W2 when 
the running average throughput exceeds thresholds Tl and T2 (Tl <= T2). WMax, WI and W2 will each be 
greater than the minimum segment size (536 bytes) and WMax Wl >~ W2. 

• Optionally, providing two levels of (non-DNS) UDP discard, Ul and U2, linked with Tl and T2 respectively 
(1<= U2 <= Ul <= 1000). If Tl is reached, every Ul*** (say, 50*'') UDP packet will be dropped and if T2 is 
reached, every U2* (say, I" that is, every) packet will be dropped. 

• Optionally giving users a better initial experience, by having the HGW not include the first X minutes (default 
= 0) of activity each day in the running average. During this time the user may run at whatever rate he can 
achieve. 

• Provide a means to enable/disable data forwarding when a user is not connected (F: enable disconnect 

forwarding) on a service plan basis. 

• Modifying DAK and HGW software so that active minutes in billing records equal connected minutes. 

• Updated auto- commissioning and Turbo-Intemet statistics 

• Modifying Auto-commissioning software to allow the configuration of Tl, T2, D, WMax, Wl, W2, Ul, U2, 
F and X on a service plan basis. The HGW reconfiguration process will also be modified to include the 
service-plan information for each user. 

The Per-Service Plan Turbo-Throttling parameters are as follows: 

• D: Duration over which Running Average Throughput is calculated, default 60 minutes. 

• WMax: Maximum window size for a TCP connection - used to limit the service plan's relative performance 
(single connection throughput), 48 kbytes is roughly equivalent to 400 kbps, 24 kbytes is roughly equivalent 
to 200 kbps. 

• Tl , T2: Throughput Thresholds - increasing throughput clamping is employed as the running average 
throughput exceeds these values. Defaults, Tl = 40kbps, T2 = 64 kbps. 

• Wl, W2: Qamped window sizes when running average throughput exceeds Tl and T2 respectively. For 
example El = 2000 bytes and W2 = 600 bytes. 

• Ul, U2: Defines the UDP discard rate when the running average throughput exceeds Tl and T2 respectively- 
For example, Ul = 50, that is, 1 out of 50 and U2 = 1, that is, 1 out of 1 (every packet). 

• F, Enable Disconnect-Data forwarding 

• X, Daily Initial Un-averaged Minutes - non-zero ensures a good initial experience for the user. 
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DirecPC^'^ Turbo-Throttling II 




DiiecPC Turbo-Throttling II is intended to provide a stricter enforcement of the Turbo-Internet fair use policy and 
to prepare for ISP Bundling. The highlights of Turbo-Throttling II include: 

• TCP connection limiting: Defines the number of simultaneous TCP connections that can be opened by a user. 

• Per-user throughput throttling: When throttled, the user's bandwidth will be shared among the TCP 
connections. This will ensure that, even with multiple connections, a user's aggregate throughput will not 
exceed the configured value. The bandwidth will be shared by dividing the window size equally among all 
"bulk- transfer** type connections. 

(Note: A connection is classified as a "bulk-transfer" connection if, in the recent past, the number of 
unacknowledged bytes exceeded a configured value, typically 1 kbytes. Otherwise, the connection is 
classified as an "interactive" connection. It may be noted that all connections start off as "interactive" 
connections and may become * 'bulk- transfer" later). 

• Change in Flow Control (FC) Mechanism: Under high load conditions, the flow control mechanism throttles 
the window size of each TCP coxmection to the same value. This has led to a condition wherein a hard- 
throttled user's TCP window is not affected at all, while a non-throttled user's TCP window may shrink to a 
size equal to the hard-throttle window size. The new FC mechanism will maintain a FC meter (with values 
from 1% to 100%); the meter value will be computed based on the load conditions on SGW. A user's 
effective window size will be determined by multiplying this percentage with the window size derived on the 
basis of his throttled state. 

• Bucket leak: New parameters will be added to specijfy the bucket leak when connected and when 
disconnected. The latter leak rate will be employed especially for users with ISP Bundling service plans, so 
that they do not stay connected at HNS' expense just to reduce their running average throughput. 

• New Per Service-Plan parameters (added to TurboInetServices table): 

- Max TCP Coimections, Connected Leak rate (kbps). Disconnected Leak rate (kbps) 

- Peak-UnThrottled Hiroughput (kbps), Peak-SoftThrottled Throughput (kbps), Peak-HardThrottie 
Throughput (kbps): These, in turn, will yield window sizes (with RTF being set on a per-HGW basis) 

• Enhanced TIStats: The following fields will be added (on a per-user basis) to the TlStats table: 

- Number of TCP connections rejected, Nimiber of Hard Throttled Minutes, MaxBulkTransfeiConns 

- Service Plan of the user. Hybrid Gateway Id, Bytes Received 

The following HGW enhancements will also be bundled with Turbo-Throttling II: 

• Local Key Table: The HGW maintains a table to store the encryption keys for each remote. This table will 
now store key information only for the remotes configured on the particular HGW. 

• Unlimited number of service plans: The last release of HGW (HGNTl.8,4) limited the service plans to 30. 
The new release (HGNT2.x) will not restrict the number of service plans. 

Backward compatibility: 

• Oracle database upgrade with no HGW upgrade: HGW will ignore the new parameters 

• HGW upgrade with no database upgrade: HGW assumes version 1 of Throttling with MaxTCPConns = 100 
and DisconnLeakRate = 0 for all service plans 
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Parameters for DirecPC™ Turbo-Throttling II 



The following data sheet explains the Turbo-Throttling parameters and lays down thumb rales for assigning values 
to these parameters. Turbo-Throttling maintains a leaky-bucket for each user; the following parameters are 
associated with the bucket (and are configurable on a service plan basis): 

• L, - Leak rate (kbps): A user downloading data at this average rate would have a zero bucket depth (B, in 
bytes). The data sent to the user over the satellite causes increase in bucket depth. Every minute, a finite 
number of bytes is subtracted from the bucket depth to account for leaking. 

• Disconnected Leak Rate (kbps): The rate at which the bucket leaks when a user is not connected. This has 
been introduced to discourage users from keeping their modem connections up in order to reduce their 
running-average; especially if they use Bundled-ISP service plans. 

• D - Duration (min): The duration over which the running average throughput (RAT) is calculated (RAT = 
B/D). RAT is displayed in Gateway statistics and is included in TIStats 

• T, - Soft-Throttle Threshold (kbps): The average data rate that a user can maintain over a period of D minutes 
without encountering any throttling. A user is soft-throttled when his bucket depth becomes greater than (T, - 
L,) * D bytes 

• Tj - Hard-Throttle Threshold (kbps): The average data rate that a user can maintain over a period of D 
minutes without encountering any hard-dirottling. A user is soft-throttled when his bucket depth becomes 

greater than (T^ - L,)* D bytes 

• Po - UnThrottled Peak Throughput (kbps): The maximum throughput that a user can get when not throttled. 
(The un-throttled window size = P© * RTT, RTF = Estimated Round-Trip Time) 

• P, - Soft-Throttle Peak Throughput (kbps): The maximum throughput that a user can get when in soft- 
throttled state. (The soft-throttle window size = P, * RTT) 



• P2 - Hard-Throttle Peak Throughput (kbps): The maximum throughput that a user can get when in hard- 
throttled state. (The hard-thxottle window size = P2 * RTT) 

The following spreadsheet provides saniple values for MoonSurfer II: 
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The following thumb rules should be adhered to: 

• T„ L, and D should be chosen such that a user can download at least 25 Mbytes (size of the biggest browser 
download) without any throttling. 

• L, should equal economically sustainable average bit rate (ABR) for a service plan, that is, L, should be such 
that the it satisfies the revenue requirements. In particular, the ABR for a service plan should be monitored 
and P, and should be adjusted until ABR equals L, (Note: To maintain a "happy" customer base, L, should 
be more than the ABR for enough users) 

• Po equals the maximum data rate for the particular service plan; T2 is typically <= Pq. 

• P, :P2 ratio should be approximately 2: 1 
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Chapter 2 
Overview 

2-1 Overview 

The Turbo-Throttling feature is designed to allow a fair access to NOC resources to all users and to 
provide performance-differentiated levels of service. It also allows throughput reduction (via window sizes) 
if average throughput over a time period exceeds (service-plan configurable) thresholds. 

The feature also changes the definition of active minutes used in Billing records to equal the actual 
"connected" minutes (instead of the previous definition of "the minutes in which some user-data traverses 
the NOC"). 

The Billing system will be required to provide a flat-file which contains the site-id and service plan 
Information for each user, say, on a daily basis. 

2-2 Deliverables 

• Updated Hybrid Gateway (WinNT) executables 

• Updated DAK software 

• SCO UNIX shell scripts and executables for uploading service-plan information from the Billing system 
and updating the Oracle Database 

• Enhanced Oracle Forms to allow changes in Turbo-Throttling parameters (on a service-plan basis) 

• Enhanced Oracle triggers to reconfigure Hybrid Gateways with change of service plan of individual 
users and/or change in Turbo-Throttling parameters 

• ACS Upgrade Procedure 

• Feature Design Document 

• Feature Integration Test Plan 

• Updated NOC Manual 

• Updated Oracle Schema Document 

• Updated DirecPC Product Technical Specification (description of ascfi-file used for updating Service 
Plan information) 

2.3 Compatibility and Expected System Impact 

This section identifies the expected impact of this feature on various subsystems and specifies the 
compatibility requirements for the feature in tabular fonnn (Table 4). The table Indicates: 

• Which system components are expected to be modified. 

• Whether new NOC hardware or third-party software is required by the NOC for this feature. This is 
important as DirecPC franchises may be required to purchase the hardware or software. 

• Whether the modified component is backwards compatible with the NOC» DAK or APPs as they 
existed prior to this feature. Backwards compatibility with earlier DAK and APP software is a 
requirement. Backwards compatibility with the NOC is highly desirable, especially for DAK and APP 
software as it allows the DAK and APP software to be released prior to upgrading the NOC. 
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Table 4. Compatibility and Expected System Impact 
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Chapter 3 
Functional Requirements 

3.1 Functional Requirements 

The following paragraphs describe the basic functional requirements of the DirecPC Turbo-Throttiing 
feature. 

3.1-1 [R:0019] Running Average Throughput 

The HGW will maintain a running average throughput for all users. The running average will be calculated 

by using leaky-bucket approach where the bucket size will depend on N, Running Average Duration 
(where N will be a configuration parameter with a default value of 60 minutes >. 

3.1.2 [R:0033] Assign initial window size based on Service Plan 

Each user should be assigned an initial per-TCP-connection window size. This window size is equal to the 
WMax parameter for the corresponding Service Plan. The user's TCP window size should never exceed 
this value. 

Starting with Turbo-Throttling II. each user will be assigned an initial Peak Throughput (PeakUnThrottled 
Throughput) which will be used, in turn, to calculate the initial TCP window size. (Window Size = 
Throughput * RTT, RTT = Round-Trip Time) 

3.1.3 [D:0022] Exclude first few minutes of usage every day from running 
average calculation 

In order to provide the user with a better Initial experience, the HGW will not include the first X minutes 
(where X is a configuration parameter, with a default value of 0) of data transfer each day in the 
calculation of running average throughput for each user. During this time, the window size should be equal 
to the WMax parameter for the corresponding Service Plan (inrespective of the user's current window 
size). WMax >= 536. 

3.1.4 [R:0034] Clamp window size based on running average throughput 

If the running average throughput exceeds a (service-plan configurable) threshold T1, the user's TCP 
window size should be clamped to W1 . Similarly, if the bucket size exceeds a higher threshold T2). the 
user's TCP window size should be clamped to W2. W1 and W2 will each be greater than 536 bytes and 
WMax >= W1 >= W2. T1 <=T2. 

Starting with Turbo-Throttling II, the window sizes will be calculated based on the Peak Throughputs 
(which are configurable on a service-plan basis). 

3.1.5 [R:00361 Per-user Throughput Throttling 

When a user is throttled, the available bandvddth (or window size) will be divided among the "bulk-transfer" 
type connections. A bulk-transfer connection is a connection which, in the recent past, has had 
unacknowledged bytes exceeding a certain threshold (Other connections are termed as "interactive'*). 
Hence all connections start as "interacth/e" and may become "bulk-transfer^ later. These definitions 
correspond to the ones used for flow controL 
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3.1.6 [R:00351 Provide two levels of UDP discard corresponding to T1 and 12 

Non-DNS UDP traffic should be discarded if the user is being throttled. Just like window size clamping, 
there should be 2 levels of UDP discard. U1 and U2 (corresponding to W1 and W2 respectively). For 
example, U1 = 50 implies that at the first level of throttling, every 50*^ UDP packet will be discarded. Note 
that 1 <= U2 <= U1 <= 1000. 

3.1.7 [R:0037] TCP Connection Limiting 

The number of TCP connections that can be opened simultaneously by a user or a site will be limited to 

the MaxConnections configured for the corresponding service plan. The statistics regarding Number of 
connections open at any instant will be available via Enhanced Turbo-Intemet statistics on a real-time 
basis. 

3.1.8 [R:0038] Bucket Leak 

Turbo-Throttling I used the Bucket Leak Rate to be the same as the Throughput Hard Threshold (T2). 
Also, the bucket leak happened only if a user was active in a particular minute. Starting with Version 2 of 
Turbo-Throttling, new parameters will be provided to specify the Bucket Leak Rate when a user is 
connected and also when a user is not connected. The Disconnected Bucket Leak Rate is being added in 
order to discourage ISP Bundled users from keeping their phone line up (at HNS' expense) just to reduce 
their running average throughput. 

-3;1r9 [D:0023] Use "connected" minutes for active minutes and running average 

calculation 

The HGW must use the actual "connected^ minutes for calculating the "active" minutes and running 
average throughput. For this purpose, the DAK software must be modified to notify the HGW about 
connection establishment, connection tear-down and connectlon-up events (connection-up event must be 
notified at periodic intervals). 

The HGW software must be modified to accept these messages and to time-out if connection tear-down 
message is not received for D minutes (where D is a configuration parameter, with a default value of 3 
minutes). This must be independent of TCP connection timeouts (idle-timeout etc). 

3.1.10 Persistent data at HGW 

The following data at the HGW needs to be maintained across user sessions and across HGW restarts: 

• [R:0025] The Last state of user (throttled/non-throttled). Number of minutes the user has been 
connected in the day 

• [D:0026] The Cun-ent Bucket Depth for a user. Minutes the user has been under hysteresis and 
number of UDP packets transmitted without any discards 

3.1.1 1 [R:0031] Disable data forwarding to a user when not logged on 

By defeult, the HGW must not forward data to a user who is not currently logged on. Data forwarding 
should be allowed on a service-piar^ t>asis. 

3.1.12 [R:0012] Update of Service Plan Information for each user 

A utility will be provided to update the Service Plan infomnation for each user (in the ACS/Oracle database) 
with the data received from the Billing subsystem. The data will be in the form of ascii-file where each line 
of the file will have a 10-character site-id. a serial number and a 2-character numeric Service Plan-id, with 
comma as the separating character. 
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3.1.13 [R:00391 Unlimited number of service plans 

The limit of 30 service plans (in version 1 of Turbo-Throttling) will now be removed. 

3.1.14 [R:0013] HGW reconfiguration 

The Hybrid Gateway reconfiguration must be triggered off whenever there is a change in the Turbo- 
Throttling parameters or a change in an individual user's service plan. 

3.1.15 [R:00421 Enhanced TIStats 

The following statistics will be added to the displayed statistics and also added to the hourly records: 

- Number of TCP connections rejected 

- Number of Hard Throttled minutes 

- Maximum Bulk Transfer Connections in the last hour 

- Bytes Received by a user in the last hour (already being displayed; added to hourly records) 

- Service Plan of user (already being displayed; added to hourly records) 

- Hybrid Gateway Id for the user (will just be added to hourly records) 

3.2 N on -Throttling requirements 

The following HGW enhancements will also be performed as part of Turbo-Throttling II: 
3.2.1 [R:0040] Local Key Table 

The HGW maintains a table to store the encryption keys for each remote. The keys are received from the 
CAC via multicast messages. These messages contain keys for all remotes. In the past, each HGW used 
to store all these keys. This behavior will be changed in the new release and only keys for remotes 
assigned to the particular HGW will be stored in the HGW. 

3-2-2 [R:00411 Change in Flow Control (FC) mechanism 

The current Flow Control mechanism provides for a FCTWS (Flow-Controlled Target Window Size). Each 
user's window size at any instant is the minimum of this Target Window Size and User's Window Size 
based on Throttled state. When a flow control message is received with latency greater than a threshold, 
the FCTWS is reduced by a certain percentage. This behavior was appropriate eariien but with Turbo- 
Throttling, this leads to a condition wherein a hard-throttled user's window size may not be affected at all 
(since it was already less than the new FCTWS) while a non-throttled user's window size may start 
shrinking, ultimately becoming comparable to that of a hard-throttled user. 

Hence, starting with Turbo-Throttling II, the HGW will maintain a Flow Control Meter (FCMeter) with values 
between 1 and 100. This FCMeter value will vary with the latency values reported by the SGW. The user's 
window size at any stage will be obtained by multiplying this value with the window size value based on 
his service plan and the state of throttling. 

3.3 Obsolete Requirements 

The following requirements were suggested in an eariier version of the Requirements document, but were 
subsequently made obsolete due to change in business plans. 

3.3.1 PC:00201 Terrestrial redirection of user traffic 

When the running average throughput of a user exceeds T bits per second (where T is a configuration 
parameter, with a default value of Infinity == 10Mbps. typical value would be 56*1024 == 56kbps). the user 
traffic will be re-directed terrestrially. 
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3.3.2 [X:0021] Return to satellite path 

Once a user has been terrestrially re-directed, the user will be switched back if both the following 
conditions are satisfied: 

• The running average throughput falls below T bits per second 

. The user's traffic has been terrestrial for at least M seconds (where M is a configuration parameter, 

with a default of 60*4 == 4 minutes) 

3.3.3 [X:0024] Updated Turbo-Internet Statistics 

The Turbo-Internet Statistics must be enhanced to include the terrestrially-redirected bytes and the 
number of minutes of terrestrial redirection for each user in an hour. The running average throughput for 
each user must also be included in the Turbo-Internet Statistics. 

3.3.4 [X:00271 Terrestrially redirect some portion of traffic at all times 

The HGW must try to make use of the ten-estrial bandwidth available by redirecting R kbps (where R is a 
configurable parameter, with a default value of 8kbps) of user traffic all the time. 

3.3.5 [X:0P28] Minimum session time 

The NOC software should ensure that each user session lasts for at least S minutes (where S is a 
- -configurable parameter, with a default value of 5 minutes). This is required to prevent users from using the. 
satellite only mode (in DAK) to download big chunks of data and then switch to Terrestnia only mode (in 
DAK). It should also be ensured that this implementation does not produce inconrect 'connect minutes" in 
billing records. 

3.3.6 [X:0029] Hourly usage notification to user 

The HGW software will be enhanced to send a periodic usage-notification message to all configured 
DirecPC remotes (this activity should consume a very small satellite bandwidth). TTie DAK software will be 
enhanced to listen for these messages and update an hour-meter display which can be started by the user 
fi-om within DirecPC Navigator Statistics. 

The hour-meter must display actual usage v/s allotted quota per month and must pop up a dialog box 
when only 5 minutes of usage are left (or on session start with less than 5 minutes left). 

3.3.7 p(:0030] Per-Servlce Plan, Per-HGW Turbo-Throttling parameters 

The following configuration parameters will be configurable on a service-plan basis in the Auto- 
Commissioning Server. Based on the user's service plan and the con-esponding service plan parameters, 
the HGW must use various Turbo-throttling mechanisms as described in the previous requirements. 

• N. Number of minutes over which the running Average Throughput is calculated 

• T, Threshold average Throughput for terrestrial redirection of user traffic 

o M, Minimum number of seconds for which the user will be ten-estrially redirected irrespective of 
whether the user's throughput falls below T before that period. 

• X, excluded minutes: First few of minutes (on a daily basis) excluded from Running average 
Throughput calculation for each user 

• R, Redirect-always throughput: Number of kbps of data which will be sent terrestrially all the lime 

• E, Enable Disconnect-Forward: If set, this will enable Data fonwarding to a user who is not logged-on 

• B Down-Rev SW Block: If enabled, downrev software will not operate through the HGW. This would 
be employed for all users signing up for new service plans so that active minutes can be ensured to 
be the same as connected minutes. 
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3-3-8 New configuration parameters for Hybrid Gateway 

The following new configuration parameters will be added (as new fields in the hybndgws table). All these 
parameters can be changed by the NOC operator and will immediately update Hybrid Gateway internal 
data structures after a Hybrid Gateway reconfiguration. 

• [X:0001] PercentTerrRedirect: The percentage of users (for example, 10% of users in a list 
organized in descending order by throughput) in a particular priority level who will be moved to 
Terrestrial Redirection (simultaneously) on detection of congestion. 

• p(:00021 CongestTimer: Whenever this timer goes off, the last received latency (from SGW) for each 
priority level is examined. If the value is greater than LatencyThresh, the PercentTerrRedirect 
highest-throughput users in that priority level will be switched to Terrestrial Redirection for duration 
equal to their TerrRedirectMin (TerrRedirectMin depends on Service Plan of user) 

• User-specific configuration parameters: Each user's configuration record will be enhanced to include 
the following parameters (each of which is imported from the corresponding Turbo Internet service 
plan): 

• [X:00031 UserType: This determines the initial priority for a user in a particular service plan 
(that is, before any Throttling mechanisms are applied). This can have the following values: 

• 0 (default): "unlimited-access" user. The interactive traffic of such a user goes as 
Highest Priority while the bulk traffic will go as Medium, Low or Lowest Priority 
depending on the running average Throughput. 

• 1 : "pay-per-byte" user. The interactive traffic of such a user goes as Highest Priority 
while the bulk traffic will go as High Priority irrespective of the running average 
Throughput. 

• p(:0004] TerrRedirectMin: Tenrestrial Redirect Minutes (Default=5 minutes, value of 0 
indicates no tenrestrial redirection for this service plan). 

• P<:0005] ThruThreshMedPrio: Throughput Threshold for Medium Priority (default: 20kbps) 

• PC:0006] ThruThreshLowPrio: Throughput Threshold for Low Priority (default: 50kbps; If 
Throughput > ThruThreshLowPrio, user gets lowest priority) 

• [X:0007] RunningAvDuration: Running Average Duration used to calculate Throughput 
(default: 60 min. minimum: 10 min, maximum: 24*60 min) 

3.3.9 New statistics at Hybrid Gateway and in Oracle Database 

The Hybrid Gateways statistics gathering (and the Oracle database) will be enhanced to include the 
following new statistics: 

• P<:0008] Mbytes downloaded/active minutes and terrestrial redirect bytes/minutes by user and 
priority level. These statistics should include total statistics and the per-application statistics and 
should be dumped on an hourty basis. 

• P<:0G09] Performance statistics which include: CPU usage, SGW latency values received (for each 
priority level), satellite throughput and terrestrial redirect throughput by priority leveL 

3.3.10 PC:0010] New priority levels at HGW and SGW 

The following new priority levels (and associated Gateway Ids) will be introduced for Turbolntemet traffic 
flowing from the Hybrid Gateway to the Satellite Gateway (Note: Priority 0 and 1 are reserved for 
Multimedia and Package Delivery traffic): 

• Priority 2/ld 1 : Interactive traffic (all service plans). This includes IP/UDP and light TCP traffic for all 
users 
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• Priority 3/ld 7: (High Priority) Bulk transfer traffic of per-Mbyte users (This includes the Basic and 

Bulk service plans) 

• Priority 4/ld 8: (Medium Priority) Bulk transfer traffic of "unlimited access" (or non-pay-by-Mbyte) 
users whose average throughput is less than ThruThreshMedPrio 

• Priority 5/ld 9: (Low Priority) Bulk transfer traffic of "unlimited access" (or non-pay-by-Mbyte) users 
whose average throughput is greater than ThruThreshMedPrio but less than ThruThreshLowPrio 

• Priority 6/ld 10: (Lowest Priority) Bulk transfer traffic of "unlimited access" (or non-pay-by-Mbyte) 
users whose average throughput is greater than ThruThreshLowPrio 

3.3.1 1 p(:001 1] Terrestrial return of Turbo-Internet traffic 

The hybrid gateway should allow for terrestrial redirection of all traffic for a user for a configured duration. 
Initially, only bulk TCP traffic will be terrestrially redirected. 

3.3.12 Hour-meter display 

The DAK software will provide a display of the hourly usage over the current month and the allotted hours 
for the month. This is covered under p<:0029] 

3.4 [R:0032] User Interface 

All user interface changes must be approved by the lead engineer responsible for user-interface design 
and development. All intemationalization issues involved in such changes must also be considered. 

3.4.1 [R:0014] Configuration of Turbo-Throttling parameters via Oracle Forms 

The Oracle Forms must be enhanced to allow configuration of Turbo-Throttling parameters (mentioned in 
[R:0030]) by the NOC operator. This enhancement should take into account any issues related to the 
intemationalization features (e.g., "internationalized" character set) inherent in Oracle 7.3 and later 
releases. 

3.5 External Interface Requirements 

This section intentionally left blank. 

3.5.1 User Interfaces/Characteristics 

This section intentionally left blank. 

3.5.2 Hardware Interfaces 
This section intentionally left blank. 

3.5.3 Software Interfaces 

This section intentionally left blank. 

3.5.4 Communications Interfaces 

This section intentionatiy left blank. 

3.5.5 Network Management Interfaces 

This section intentionally left blank. 

3.6 Expected Enhancements 

This section intentionally left blank. 
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Chapter 4 
System Attributes 

This section documents the non-functional requirements of DirecPC Turbo Throttling feature, 

4.1 Performance 

4.1.1 [R:0015] No impact on existing Billing/Performance statistics 

Turbo Throttling must not affect the Billing/Performance statistics being gathered at present, except that 
the active minutes will now equal "connected" minutes. 

4.2 Capacity and Resources 

This section intentionally left blank. 

4-3 Scalability 

This section intentionally left blank. 

4.4 Design Constraints 

This section intentionally left blank. 

4.4.1 [R:0016] Standards Compliance 

All phases of implementing the requirements set forth in this document shall be ISO 9001 compliant as set 
forth by HNS ISO 9001 procedures and practices. 

4.4.2 Hardware Limitations 

This section intentionally left blank. 

4.4.3 Physical Environment Considerations 

This section intentionally left blank. 

4.4.4 Timing Constraints 

This section intentionally left blank. 

4.4.5 [R:0D17] Software Compatibility/Environment Considerations 

The feature must operate on Windows NT HGW and must be compatible with other OS/2 or WinNT MUX 
components. 

4.4.5.1 [R:0043] Backwards Compatibility 

1 . If the database is upgraded without a particular HGW being upgraded, that HGW will just ignore the 
new parameters. Or if the new version of HGW Is replaced by the older version, it will continue to 
function as before. 

2. If the HGW is upgraded without a database upgrade, the HGW will assume a value of 100 for 
MaxTCPConnecUons for all service plans. Also it will assume Throttling I, with DisconnLeakRate = 0. 
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4.4.6 Unit Cost 

This section intentionally left blank. 

4.5 Time to Market 

This section intentionally left blank. 

4.6 Testability 

This section intentionally left blank. 

4.7 Attributes 

This section intentionally left blank. 

4.7.1 Availability 

This section intentionally left blank. 

4.7.1 .1 Startup/Recover Time 

This section intentionally left blank. 

4.7.1.2 Fault Tolerance 

This section intentionally left blank. 

4.7.1.3 Mean Time Between Failure (IVITBF) 

This section intentionally left blank. 

4.7.2 Security 

This section intentionally left blank. 

4.7.3 Privacy 

This section intentionally left blank. 

4.7.4 Debugging/Trace Capability 

This section intentionally left blank. 

4.7.5 [R.001 8] Maintainability 

The following new documents will be created for this feature: 

• DirecPC Turbo Throttling Feature Requirements Specification (Pubs No. HNS-1 1232) 

• DirecPC Turbo Throttling Feature Design Specification (Pubs No. HNS-1 1422) 

• DirecPC Turbo Throttling Feature Integration Test Plan (Pubs No. HNS-12090) 
The following documents will be updated for this feature: 

• DirecPC NOC Manual (Pubs No. HNS-7013). 

• DirecPC Hybrid Internet Technical Specification (Pubs No. 8050744) 

• DirecPC Oracle Schema Document (Pubs No. HNS'6896) 

• DirecPC Product Technical Specification (Pubs No. 8050134) 
The following are the other deliverables: 
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• Executables for WinNT-based HGW 

• New DAK software 

• SCO UNIX shell scripts and executables for uploading service-plan infonmation from the Billing 
system and updating the Oracle Database 

• Enhanced Oracle Forms to allow changes in Turbo-Throttling parameters (on a service-plan basts) 

• Enhanced Oracle triggers to reconfigure Hybrid Gateways with change of service plan of individual 
users and/or change in Turbo-Throttling parameters 

• ACS Upgrade Procedure 

4.7.6 Adaptability 

This section intentionally left blank. 

4.7.7 Portability 

This section intentionally left blank. 

4.8 Installation Requirements 

This section intentionally left blank. 

4.9 Customization Requifemerits " " 

This section intentionally left blank. 

4.10 Other Requirements 

This section intentionally left blank. 



EXHIBIT 3 



Roderick Ragland 
02:14 PM 

To: D^ve Zatloukal/HNS@HNS, Doug Dillon/HNS®HNS , Ramesh Belani/HNS®HNS, 

Bill Donnellan/HNS©HNS, Tom Naugler/HNS@HNS , Matt Kenyon/HNS@HNS 
cc: John Kenyon/HNS@HNS, Vivek Gupta/HNS®HMS, Richard Lodwig/HNSOHNS 

Subject: Traffic Management Meeting Minutes 

Attached is a copy of the traffic mangement meeting minutes for your 
review. The next meeting will be in Dave's office on Wednesday! 
at 9:00am. ^ ' 



Rod Ragland 

(See attached file: TMMM 



l.doc) 



Traffic Management Meeting Minutes 

ATTENDEES: Dave Zatloukal, Doug Dillon, Rod Ragland 

DATE: Wednesday.llUllllllHBIV^ 

SUBJECT: Weekly Status Meeting 
AGENDA 




4) Doug presented his detailed spread sheet analysis of the Turbo-throttling n parameters per service. 



ACTIONS ITEMS 




3) Rod will analyze MoonSurfer statistics from Turbo-Throttie II gateways. From his analysis it will 
show: percentage of minutes throttled against total; percentage of users throttled; histogram of records 
sorted by throughput over the hour; histogram of users sorted by total Mbytes; and, histogram of users 
sorted by connect time (to be completed within 1 week). 



EXHIBIT 4 



Harvey Lindenbaura 




04:36 PM 



To: John Kenyon/HNS@HNS, Barbara Stavely/HNS@HNS, fkeliy 

cc: Ramesh Belani/HNS0HNS, bstanton, Mark Petronic/HNS@HNS, William 

Chao/HNS@HNS, Doug Dillon/HNSOHNS, ifaenson, Jerry Longo/HNS@HNS, 
Vivek Gupta/HNS@HNS, Satyajit Roy/HNS(3HNS, murr, Vaishali 
Sesha/HNSQHNS, Anuj Varma/HNSGHNS, Roderick Ragland/HNS@HNS, Tsanchi 
Li/HNSGHNS, Gabriel 01ariu/HNS8HNS, Anil Vohra/HNS@HNS, msyed, Trung 
Tran/HNS@HNS, Matthew Baer/HNSeHNS, Rajeev Kubba/HNS@HNS 

Subject: DirecPC Weekly Report 

ENGINEERING WEEKLY REPORT BY PRODUCT LINE 



WEEK ENDING: 




PROJECT LEADER: Harvey Lindenbaum 



PRODUCT LINE: DirecPC JOB NUMBER: 12542, 1254 3 

PRODUCT: DirecPC 
RED FLAG ITEMS: None 
MAJOR ACCOMPLISHMENTS/MILESTONES: 
Turbo Throttling 2 

FIT testing of Turbo Throttling 2 has been completed. It has been turned 
over to 

Ramesh Belani for Release Testing. 
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